基于顶级 Agent（Claude Code）的 Harness 工程搭建式业务 Agent 评测方案
泊予 2026年6月5日 08:30
阿里妹导读
用一个强 Agent 构建评测 Harness，系统性评测一群业务 Agent（文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。）
一、背景与问题
1.1 业务场景
某业务系统的内容生成链路由多个子 Agent 协作完成，每个 Agent 负责不同的任务（图片理解、内容审核、文案生成、风格匹配等）。这些 Agent 的 prompt 方案频繁迭代，每次变更后需要快速验证效果。
核心矛盾：业务 Agent 迭代快（天级），但传统评测工程搭建慢（周级）。
1.2 传统评测的痛点
| 痛点 | 表现 |
|---|---|
| 启动成本高 | 搭建评测工程、写脚本、部署服务，还没开始评就花了一周 |
| 人力密集 | 标注数据集、写分析脚本、出报告，每个环节都需人工介入 |
| 迭代慢 | prompt 改了一行，想看效果要等半天重新跑 |
| 可复现性差 | 评测逻辑散落在各种脚本和 Notebook 里 |
| 指标不统一 | 不同 Agent 各搞一套，无法横向对比 |
| 工程化沉重 | 每换一个 Agent 就要新写一套评测代码 |
1.3 我们的解法：Harness 工程搭建式评测
核心思路：用一个顶级 Agent（Claude Code）作为 Harness 工程的搭建者和运行者，系统性地对业务 Agent 进行评测。
什么是 "Harness 工程搭建式"？
传统做法：人写评测代码 → 跑脚本 → 看结果 → 改代码 → 再跑
Harness 式做法：顶级 Agent 搭建完整的评测骨架（harness），包括评测方案、数据集、评测逻辑（以 Agent 提示词形式表达）、分析流程。人只需提供被测对象和做关键决策。
为什么 Claude Code 是合适的 Harness 搭建者？
| 能力 | 在 Harness 中的作用 |
|---|---|
| 深度理解 prompt | 分析被测 Agent 的逻辑，设计针对性评测维度 |
| 代码生成 | 数据获取/处理脚本，评测辅助工具 |
| 结构化输出 | 评测方案文档、评测 Agent 提示词、评测报告 |
| 多轮协作 | 跨版本持续迭代（v1→v2→v3），保持上下文连贯 |
| 数据分析 | 对跑批结果做统计、归因、对比 |
关键洞察：评测 Harness 的本质是一套结构化的评估规则 + 执行流程。传统做法把它编码为 Python 脚本，而我们把它编码为 Agent 提示词——更灵活、更可读、更易迭代。
二、Harness 工程整体架构
2.1 三层架构
' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3)
)
2.2 Harness 搭建五步法
)
2.3 与传统评测工程的类比
| 传统评测工程 | Harness 式评测 | 变化 |
|---|---|---|
test_config.yaml |
评测方案.md | 规则从配置文件变为自然语言文档 |
test_data.json |
评测集 Excel（system.question） | 数据格式统一，人可直接看懂 |
test_runner.py （数百行） |
评测 Agent 提示词（数千字） | 执行逻辑从代码变为 Prompt |
conftest.py + fixtures |
GT 标注 + ground_truth 字段 | 预期结果内嵌在数据中 |
report_generator.py |
CC 实时分析 | 报告生成从脚本变为交互 |
requirements.txt + CI |
评测平台一键跑批 | 零部署成本 |
2.4 职责分工
| 角色 | 职责 | 不做什么 |
|---|---|---|
| 人 | GT 标注、方案审核、最终决策 | 不写评测脚本、不手动计算指标 |
| Claude Code | Harness 全链路搭建 + 结果分析 | 不做批量推理主循环（交给平台） |
| 评测平台 | 批量执行引擎（逐行调用） | 不做方案设计和指标汇总 |
三、统一评测指标框架
3.1 三层指标体系
)
在评测 6 个不同类型的 Agent 后，我们沉淀了一套通用的三层指标框架：
L1：通用基础指标（所有 Agent 必报）
| 指标 | 含义 | 为什么重要 |
|---|---|---|
| 输出格式合规率 | JSON 可成功解析的比例 | 下游消费方直接报错 |
| 字段完整率 | 必要字段均存在的比例 | 缺字段 = 功能不可用 |
L2：按能力类型选用（从菜单中按需勾选）
| 能力类型 | 指标 | 适用场景 |
|---|---|---|
| 分类判断 | 分类准确率 | 枚举值选择（如类型判断） |
| 二元决策 | 召回率 / 精确率 | 过滤 / 准入决策 |
| 数值提取 | 精确匹配率 | 离散数值的精确提取 |
| 连续评分 | MAE + 分档一致率 | 内容质量打分 |
| 文本生成 | LLM-as-Judge 1-5 分 | 文案、描述等开放式输出 |
L3：Agent 专属指标（按需自定义）
每个 Agent 可在 L1+L2 基础上追加专有指标。例如：
●文案生成 Agent：违禁词清洁率、关键信息保留率
●风格匹配 Agent：不适用风格过滤合规率
3.2 新 Agent 接入时的指标选型流程
确定 Agent 涉及的能力类型↓从 L2 菜单勾选对应指标↓按需追加 L3 专属指标↓设定每个指标的目标阈值
四、Harness 各层的搭建方法
4.1 规则层：
评测方案设计（CC 角色：方案架构师）
输入：被测 Agent 的 prompt 文件 + 业务上下文描述
CC 输出：
●完整的评测方案文档（含维度、指标、阈值、数据集要求、错误分类体系）
●边界用例建议（CC 分析 prompt 逻辑后主动提出应覆盖的场景）
实际效果：从一个 prompt 文件到一份完整评测方案，大约 10 分钟的交互。
示例对话：
人：这是新的内容审核 Agent 的 prompt，帮我设计评测方案CC：[分析 prompt] 我建议从以下维度评测：1. 格式合规（JSON可解析 + 字段完整）2. 过滤决策（召回率/精确率）3. 评分准确性（MAE + 分档一致率）需要覆盖的边界：少量输入/全过滤/极端分数...目标阈值建议：过滤精确率≥90%，MAE≤3...人：某个维度容易低估，阈值放宽到 MAE≤5CC：好的，已更新。[输出完整方案文档]
4.2 数据层：
黄金评测集构建（CC 角色：数据工程师）
CC 做的事：
1.数据获取：编写脚本调用业务接口，批量拉取候选数据
2.数据处理：格式化为评测所需的 JSON 结构
3.GT 辅助标注：对分类型指标，CC 先给建议标注，人工复核
4.评测集打包：生成评测平台可直接消费的 Excel（含 system.question 列）
关键设计：system.question 列
每行数据都有一个system.question列，格式为 JSON，包含：
●被测 Agent 所需的全部输入字段
●ground_truth（人工标注的黄金答案）
评测 Agent 读取这一列即可获得输入和预期输出，无需额外配置。
{ "sample_id": 243, "title": "XX品牌零食合集...", "content": "最近发现了...", "items": [...], "ground_truth": { "should_filter": false, "total_score": 64, "dimension_a": 22, "dimension_b": 22, "dimension_c": 20 }}
4.3 执行逻辑层：评测 Agent 提示词
（CC 角色：Harness 工程师）
)
这是整套方案最核心的创新：把传统的评测脚本（Python/Java）替换为一份评测 Agent 提示词。评测逻辑从"代码"变为"自然语言指令"，一个 Agent 来评测另一个 Agent。
评测 Agent 的工作流程：
读取 system.question（一行数据） ↓调用被测 Agent（获取实际输出） ↓解析输出 → 硬规则自动检查 → LLM 打分 ↓输出结构化 JSON（所有指标的计算结果）
评测 Agent 提示词的结构模板：
##角色定义你是一个严谨的 AI 评测专家，负责对「XXX」Agent 进行单条样本评测。##工具声明-{agentId}：调用被测 Agent，传入 XXX，返回原始输出##约束1.必须先调用工具获取 Agent 输出，再评测2.最终只输出一个合法 JSON3.数值统计必须精确计算，不可估算##工作流程1.解析输入（提取 post_id、输入数据、ground_truth）2.调用被测 Agent3.解析输出为 JSON4.硬规则自动检查（格式/字段/枚举/字数/...）5.LLM-as-Judge 打分（对比 ground_truth 或按评分标准）6.错误归因（FORMAT_ERROR / WRONG_CHOICE / ...）7.输出最终 JSON##输出 Schema{完整的 JSON schema 定义}
为什么要这样设计？
| 优势 | 说明 |
|---|---|
| 逻辑可读 | 评测逻辑以自然语言写在提示词里，无需读代码 |
| 快速迭代 | 发现评测逻辑有误，改一段文字就行，不用改代码重部署 |
| 统一执行 | 所有 Agent 的评测逻辑结构一致，只改内容不改框架 |
| 评测即文档 | 提示词本身就是评测标准的完整说明 |
4.4 输出层：
结果分析与报告（CC 角色：数据分析师）
典型流程：
人：跑批完了，结果在 XXX.xlsx，帮我出报告CC：[读取 Excel]- 总量 50 条，API 成功 46 条- 格式合规率 92%- 过滤 Recall 100% / Precision 18.2% ❌- 核心问题：模型将评分维度误用为过滤条件- 建议：修复 prompt 中过滤逻辑的边界定义[输出完整报告 Markdown]
CC 在分析中的增值：
1.自动识别 pattern：不只报数字，还归因（"18 条误过滤中，12 条都是把某评分维度<60 当过滤条件"）
2.跨批次对比：和上一版结果对比，明确哪些指标进步/退步
3.给出可操作建议：不只是"分数低"，而是"建议在 prompt 第三段加入明确的过滤条件边界"
五、关键实践经验
5.1 评测集设计原则
| 原则 | 说明 | 反例 |
|---|---|---|
| 小而精 | 20-55 条足够，覆盖所有边界场景 | 200+ 条但都是简单 case |
| 分布均衡 | 正/负例比例合理，边界场景必须有 | 全是正例，评不出问题 |
| GT 可复核 | 每条 GT 标注有据可查 | GT 靠感觉打分 |
| 版本化管理 | 评测集跟随被测 prompt 版本变更 | 用 v1 评测集评 v3 prompt |
5.2 评测 Agent 提示词的迭代策略
我们发现评测 Agent 本身也需要迭代（评测系统 bug ≠ 被测 Agent bug）：
常见评测系统 bug：
| 问题 | 表现 | 修复方式 |
|---|---|---|
| 匹配逻辑过严 | 语义等价的判定原因被判错 | GT⊆AI 超集匹配 |
| 硬编码规则误报 | 排除列表不全导致误判 | 改为动态语义比对 |
| Token 截断 | 输出超长被评测平台截断 | 正则容错提取关键字段 |
| GT 覆盖缺口 | 新增选项未在 GT 中体现 | 更新 GT 标注 |
迭代节奏：
●v1：基本逻辑跑通（调试模式，带推导过程）
●v2：切换为跑批模式（纯 JSON 输出），修复首批发现的评测逻辑 bug
●v3+：基于实际结果持续调优（指标定义、匹配方式、容错逻辑）
5.3 LLM-as-Judge 的使用心得
对文本生成类 Agent（无法精确匹配 GT），我们用 LLM 做评委：
做法：在评测 Agent 提示词中嵌入评分标准（1-5 分 rubric），评测 Agent 同时扮演"执行者"和"评委"。
有效的 rubric 设计：
5 分：改写自然，传达原文单一核心意图，一次读完即懂4 分：基本达标，有轻微瑕疵但整体可读3 分：勉强可接受，但存在轻度问题2 分：明显问题：信息压缩过度或照抄原文1 分：严重错误：与输入无关或完全无法理解
注意事项：
●每个分值必须有具体、可区分的判定标准
●避免"好/较好/一般"这类主观描述
●分值之间的差异应该一个正常人也能判断
5.4 "评测 Agent 调被测 Agent" 的技巧
评测平台→ 调用评测 Agent（一个 LLM 实例）→ 评测 Agent 通过工具调用被测 Agent（另一个 LLM 实例）→ 获得被测 Agent 的原始输出→ 评测 Agent 对输出进行多维度评分→ 返回结构化评测 JSON
实际踩坑：
| 坑 | 解法 |
|---|---|
| 评测 Agent 忘记调用工具 | 在 Constraints 中强调"必须先调用工具" |
| 工具参数传递失败 | 在提示词中显式写明参数构造逻辑 |
| 评测 Agent 重试耗尽 token | 添加"禁止重试"约束 |
| 输出截断 | 减少推导过程，只输出最终 JSON |
六、效率对比
)
6.1 时间投入
| 阶段 | 传统方式 | CC 协助 | 加速比 |
|---|---|---|---|
| 评测方案设计 | 1-2 天 | 10-30 分钟 | ~10x |
| 评测集构建 | 2-3 天 | 半天（含人工标注） | ~5x |
| 评测脚本/Agent 开发 | 2-3 天 | 1-2 小时 | ~10x |
| 跑批执行 | 同（平台执行） | 同 | 1x |
| 结果分析 + 报告 | 半天-1天 | 10-20 分钟 | ~5x |
| 单 Agent 全流程 | ~1.5 周 | ~1-2 天 | ~5x |
6.2 质量保障
CC 方案不仅更快，分析质量往往更高：
●覆盖性：CC 不会遗漏任何数据行（人工数 50 行 Excel 容易看漏）
●一致性：同样的评测标准，CC 不会因为疲劳而评分漂移
●溯源性：每条评测结果都可追溯到 prompt 中的具体逻辑
●可复现：同一份评测 Agent 提示词 + 同一份评测集 = 结果可复现
七、适用场景与局限
7.1 适用场景
| 场景 | 适合度 | 原因 |
|---|---|---|
| Prompt 迭代验证 | ⭐⭐⭐⭐⭐ | 改 prompt → 跑批 → 看报告，闭环最快 |
| 多 Agent 横向对比 | ⭐⭐⭐⭐⭐ | 统一指标框架 + 相同评测流程 |
| 新 Agent 上线前验收 | ⭐⭐⭐⭐ | 系统性覆盖，不依赖人工抽检 |
| 线上问题复盘 | ⭐⭐⭐ | 可快速构造问题用例验证 |
7.2 局限与建议
| 局限 | 建议 |
|---|---|
| LLM-as-Judge 本身有偏差 | 对关键决策用人工抽检兜底 |
| 评测集规模受限（人工 GT） | 小而精优于大而糙，20-55 条覆盖边界即可 |
| 依赖评测平台稳定性 | token 截断、API 超时需做容错 |
| 首次搭建有学习成本 | 第二个 Agent 起复用率很高 |
八、可复用资产
经过 6 个 Agent 的实战，已沉淀的可复用资产：
| 资产 | 说明 | 复用方式 |
|---|---|---|
| 三层指标框架模板 | L1/L2/L3 | 新 Agent 对照选用 |
| 评测方案文档模板 | 目标+维度+数据集+流程+错误分类 | 填空式生成 |
| 评测 Agent 提示词模板 | 角色+工具+约束+工作流+输出 schema | 替换业务逻辑即可 |
| 评测集 Excel 格式 | system.question 列规范 | 标准化接入评测平台 |
| 评测报告模板 | 执行情况+指标汇总+问题分析+建议 | CC 自动填充 |
| 错误分类体系 | FORMAT_ERROR/WRONG_CHOICE/... | 按需扩展 |
| Agent 平台调用经验 | 接口格式/参数/踩坑记录 | 减少试错 |
九、快速上手指南
想要复用这套方案的同学，按以下步骤操作：
Step 1：准备工作（5 分钟）
●准备好被测 Agent 的 prompt 文件
●确认被测 Agent 的接口信息和调用方式
●在 Claude Code 中打开项目目录
Step 2：设计评测方案（10-30 分钟）
告诉 CC：这是被测 Agent 的 prompt [粘贴/路径]，帮我设计评测方案。CC 会输出：维度、指标、阈值、数据集要求、错误分类。你来审核和调整。
Step 3：构建评测集（半天，含人工标注）
告诉 CC：帮我从 XXX 接口拉取候选数据，格式化为评测集。CC 输出：候选数据 Excel。你来做 GT 标注（CC 可以先给 AI 建议，你复核）。CC 打包为带 system.question 列的最终评测集。
Step 4：编写评测 Agent 提示词（1-2 小时）
告诉 CC：基于评测方案，帮我写评测 Agent 的提示词。CC 输出：完整的评测 Agent System Prompt。上传到评测平台，用 1-2 条数据调试。根据调试结果让 CC 修改（通常需要 2-3 轮）。
Step 5：跑批 + 出报告（30 分钟）
上传评测集到平台 → 等待跑批完成。下载结果 Excel → 告诉 CC：帮我分析这份结果。CC 输出：完整评测报告 + 优化建议。
十、总结
10.1 核心理念
一句话：用一个强 Agent（Claude Code）搭建评测 Harness 工程，将评测逻辑从"代码"升级为"Prompt"，实现业务 Agent 的系统性快速评测。
范式转变：
传统：人写评测代码 → 跑脚本 → 人看结果 → 人改代码 → 再跑（周级启动，天级迭代）Harness式：CC搭建Harness → 平台跑批 → CC分析 → CC调整Harness → 再跑（天级启动，小时级迭代）
10.2 核心收益
| 收益 | 具体表现 |
|---|---|
| 从周到天 | 单 Agent 评测全流程从 ~1.5 周压缩到 1-2 天 |
| 一人成军 | 一个人 + Claude Code 完成原来需要测试开发 + 数据标注 + 分析师的工作 |
| 可持续迭代 | 每次 prompt 变更后的验证成本极低（改提示词 → 重跑 → 看报告） |
| 零部署 | 评测逻辑是 Prompt 而非代码，无需 CI/CD，改完即生效 |
| 方法论沉淀 | 指标框架 + Agent 提示词模板 + 错误分类体系，可迁移复用到任何 Agent |
10.3 适用场景
●任何有 Agent/LLM 应用、需要系统性评测能力的业务组
●Prompt 迭代频繁（天级/周级），需要快速验证效果
●多 Agent 协作系统，需要分模块独立评测
10.4 开放讨论
| 问题 | 思考 |
|---|---|
| 评测 Agent 自身的准确性如何保证？ | 调试期用 2-3 条数据人工核对；正式跑前先小批次验证 |
| 能否替代人工测试？ | 不能完全替代，但可以覆盖 80%+ 的重复劳动 |
| 与 Evals 框架（OpenAI）的关系？ | 理念类似，但我们的 Harness 更轻量、更灵活、无需工程部署 |
| 能否跨团队复用？ | 可以——三层指标框架 + 评测 Agent 模板 + 工作流模板，换被测对象即可 |
十一、最后
感谢对营销消费清单 AI 项目评测专项给予大力支持和鼓励的各位老师：
团队战友：岑坚、茉书、沈芃、飘飘、鲜佳伟等同学
协作兄弟：危素、朱八、墨謧、临汀、图兔、书屹、深空等同学
继续滑动看下一个
阿里云开发者
向上滑动看下一个